Release 10.1A: OpenEdge Getting Started:
Database Essentials

Tuning your system

To the inexperienced administrator, time spent waiting for I/O seems highly undesirable. If I/O wait is having a noticeable impact on performance, it is clearly an issue. However, not all wait for I/O is cause for concern. Time is reported to this statistic whenever the CPU has completed a task and is waiting for some other system resource, such as disk or memory. Given that CPUs are much faster than other resources, the CPU must wait for these slower resources some percentage of the time.

In tuning a system, it is desirable to have some idle time available, but this is not a necessity. It is possible to use 100 percent of the CPU time on a two-CPU system with two processes. This would not mean that the system was performing poorly; this means the system is running as fast as it can run. In performance tuning, you are trying to push the bottleneck to the fastest resource, the CPU. Given ideal circumstances, it is best to have 70 percent user time, 20 percent system time, 0 percent wait for I/O, and 10 percent idle time.

The ratio of user time to system time should be approximately 3 to 1. However, this ratio varies widely when user time is below 20 percent of total CPU usage, as system time tends to consume a much larger portion. In some cases, system time is greater than user time due to poor allocation of resources. However, as you increase user time through performance tuning, system time should level off at around one-third or less of user time. This can be determined by looking at your CPU resources from any monitoring tool of your choice.

Indications that you are out of CPU resources might only be masking an issue with another resource. In most cases it is a disk issue. If you see a CPU bottleneck, first, ensure that you do not have a runaway process. Second, make sure that your other resources are working efficiently.

CPU usage and the -spin parameter

Broker-allocated shared memory can be updated by multiple clients and servers. To keep shared memory from being updated by two users simultaneously, OpenEdge uses spin locks. Each portion of memory contains one or more latches to ensure that two updates cannot happen simultaneously. When a user modifies a portion of shared memory, the user gets a latch for that resource and makes the change. Other users who need the resource respect the latch. By default, if a latch is established on a resource and a user needs that resource, that user tries for the resource once and then stops trying. On a single CPU system, you only want to try the operation once because the resource cannot be freed until the resource that has the latch can use the CPU. This is the reason for this default action.

On a multiple CPU system, the default action is not very efficient because a significant amount of resource time is used to activate a different process on the CPU. This effort is wasted if the resource is not available. Typically, a resource is only busy and latched for a very short time, so it is more efficient to ask to obtain the resource many times rather than ask once, go to the end of the CPU queue, and when arriving at the top of the CPU queue, ask a second time to get the resource. The –spin parameter determines the number of retries before giving up.

Generally, a setting between 2,000 and 10,000 works for the majority of systems, but this varies greatly. Monitor the number of “naps per second” per resource. If the naps-per-second value for any given resource exceeds 30, try increasing the value of –spin. You can do this while the system is running through the PROMON R&D option.